組織がアジャイルな考え方を取り入れる場合、エンタープライズアーキテクチャは消滅するわけではありませんが、エンタープライズアーキテクトの役割は変化します。エンタープライズアーキテクトはもはや自ら選択を行うのではなく、他者が正しい選択を行うのを支援し、その情報を共有する役割を担います。エンタープライズアーキテクトは依然としてビジョンを形成する必要がありますが、学習コミュニティを構築するためにチーム間の橋渡しを行う必要があります。これにより、チームは新しいアプローチを探求し、互いに学び合うことができ、エンタープライズアーキテクトはその成長におけるパートナーとなります。

テクノロジーを効果的に活用するには、テクノロジーに関する考え方と根本的なビジネスプランを一致させる必要があります。テクノロジー戦略は、ビジネスとテクノロジーを適切に統合することで、この整合性を推進できます。私たちは、戦略的イニシアチブの共通点を認識することに基づいて、この戦略的思考を支援するための概念フレームワークを開発しました。これにより、11の一般的な戦略的方向性を特定することができました。それぞれの方向性について、それが提起する主要なビジネス上の課題と、テクノロジーへの影響を探るために実施する必要がある調査の概要を示します。このフレームワークは、より効果的なテクノロジー戦略につながるだけでなく、テクノロジーがビジネス思考に情報を提供し、新しい収益源を生み出すことを可能にすることがわかりました。

私たちと私たちの同僚は、しばしばクライアントのためにアーキテクチャ評価を行うよう依頼されます。この際、これらのシステムに携わっているアーキテクトは、これらのシステムのパフォーマンス、障害に対する復元力、新しい機能を容易にサポートするように設計されている方法について説明します。しかし、ほとんど話題に上らないのが、さまざまなシステムがビジネス価値にどのように貢献するか、そしてこの価値が他のアーキテクチャ属性とどのように相互作用するかです。

アーキテクチャは、少数の中央集権的な人々の頭脳と口からトップダウンで伝えられる独白である必要はありません。この記事では、分散型で権限委任された意思決定手法によって推進され、意思決定記録、諮問フォーラム、チーム主導の原則、テクノロジーレーダーという4つの学習と整合メカニズムによってサポートされる、会話の一連としてアーキテクチャを行う別の方法について説明します。

Xapoはビットコインサービスプロバイダーとして設立され、オンライン銀行へと発展しました。この移行において、ソフトウェア資産を再評価し、将来を導くアーキテクチャ機能を確立する必要がありました。ドメイン駆動設計、チームトポロジー、アーキテクチャアドバイザープロセスからのアイデアを採用して、アーキテクチャアドバイザリーフォーラムを開発しました。これにより、ソフトウェアデリバリーチームの整合性が向上し、一貫性のあるテクノロジー戦略が実現しました。

経営陣はメトリクスを好みます。「現状を測定する数値が必要です。数値は人々に焦点を当てさせ、成功を測定するのに役立ちます。」という考えです。善意に基づいていますが、数値による管理は直感に反して問題のある行動につながり、最終的にはより広範なプロジェクトと組織目標から目をそらすことになります。メトリクス自体は悪いものではありません。ただ、多くの場合、不適切に使用されているだけです。このエッセイでは、経営陣による従来のメトリクスの使用によって引き起こされる多くの問題を示し、これらの機能不全に対処するための代替案を提供します。

これはミュンヘンで開催されたOOP 2014での基調講演の第2部であり、説明するのが難しい講演です。通常、講演の内容を説明するタイトルと要約を好みますが、この講演は旅であり、どこに向かっているかを伝えるのではなく、一緒に地面を探求したいと考えています。アジャイルソフトウェア開発の採用における私の最大の課題、つまりユーザー、アナリスト、プログラマー間の相互作用の本質から始まります。そして、これらの役割を探求し、プログラマーとユーザーの関係、彼らに対する私たちの責任、そして最後にプログラマーが直面する必要があると考えている2つの大きな課題について疑問を呈します。

私の著作を読んだ方ならご存知のとおり、私は進化型設計の熱心な支持者です。このアプローチに対する私の熱意にもかかわらず、どの手法も完璧ではなく、成功と同じくらい問題についても喜んで報告します。

採用状況を想像してみてください。どちらも数年の経験を持つ2人の候補者がいます。ブルーコーナーには、あなたが好む設計スタイル（私の場合、DRY、パターンの慎重な使用、TDD、コミュニケーションを重視したコードなどですが、実際のリストは重要ではなく、あなたが好むものということです）で幅広い設計スキルを持つ人がいます。しかし、彼女はあなたが使用している特定のプラットフォームテクノロジーについて何も知りません。レッドコーナーには、これらの問題についてほとんど知識（または関心）がありませんが、あなたのプラットフォームをよく知っている人がいます。言語のエッジケース、使用可能なライブラリ、ツールを自然に操作する指先などです。それ以外の点はすべて同じであると仮定します（この種の思考実験以外では決してそうではありません）そして、あなたのチームにこの候補者が埋めることができる大きな穴がないと仮定します。どちらを優先しますか？